Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace attrdict with NamedTuple #76

Merged

Conversation

cburgdorf
Copy link
Contributor

What was wrong?

The usage of attrdict dependency was causing a deprecation warning.

  from collections import (
/home/cburgdorf/Documents/hacking/ef/trinity/venv/lib/python3.7/site-packages/attrdict/mixins.py:5: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working

How was it fixed?

Replaced with NamedTuple which should have the positive side effect of a stronger guarantee of immutability.

Cute Animal Picture

put a cute animal picture link inside the parentheses

@cburgdorf
Copy link
Contributor Author

review ping @pipermerriam

Copy link
Member

@pipermerriam pipermerriam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would be a breaking change and while I'm 👍 on moving this direction, I don't think we an do it immediately. It doesn't appear that this is fixed upstream, nor has there been a release in about 11 months.

I'd recommend pursuing an upstream fix for this first and seeing if the library maintainers can get it merged and released so we can address this without a major bump.

Second option is to use something like this and vendor it for the time being: https://github.com/ethereum/web3.py/blob/c1c80dba4d9c203af7a4963bf1ce5e922f1172da/web3/datastructures.py

I'm good with us eventually switching to a NamedTuple but I consider this library to be somewhat foundational and thus a major version bump in it is going to need to be taken carefully and probably shouldn't happen until sometime in January when all this holiday nonsense has passed.

@cburgdorf
Copy link
Contributor Author

It doesn't appear that this is fixed upstream, nor has there been a release in about 11 months.

The inactivity there was part of the reason why I believe it is not worth to try to get this fixed upstream. I wouldn't expect to this to result in an upstream release in a short time frame which is why I thought it is better to fix it on our on end. Especially if we consider that modern Python has no need for that library any more.

Second option is to use something like this and vendor it for the time being: https://github.com/ethereum/web3.py/blob/c1c80dba4d9c203af7a4963bf1ce5e922f1172da/web3/datastructures.py

But wouldn't that be as much of a breaking change as just going with NamedTuple? I'm assuming the breaking part is just the underlying object that is being returned and maybe the repr_pretty which I could still put back in. Other than that, the solution proposed in the PR is attribute access compatible.

Someone calling signTransaction can still access signed_tx.rawTransaction or any other attribute like before. I might be missing some other subtle breaking change?

I'm good with us eventually switching to a NamedTuple but I consider this library to be somewhat foundational and thus a major version bump in it is going to need to be taken carefully and probably shouldn't happen until sometime in January when all this holiday nonsense has passed.

Yeah, no rush. I'd probably say, let's just wait and cut a new major release some time in January.

@pipermerriam
Copy link
Member

It is a breaking change because named tuples don't support dictionary style key retrieval. Whatever we return needs to support both attribute and string-based key lookups via the standard Mapping interface to retain backwards compat.

@cburgdorf
Copy link
Contributor Author

string-based key lookups

Ah! That makes sense. Thanks for clarifying.

@veox
Copy link
Contributor

veox commented Jan 7, 2020

2c: probably means there needs to be a test for this.


As to the previous

The inactivity there was part of the reason why I believe it is not worth to try to get this fixed upstream. I wouldn't expect to this to result in an upstream release in a short time frame which is why I thought it is better to fix it on our on end.

There will be no release: the ustream repo has been archived by the owner.


On a brighter side, the deprecation has been moved to Python 3.9 since original post:

/home/veox/src/trinity/.virtualenv/trinity/lib/python3.7/site-packages/eth_account/account.py:1:
    DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc'
    is deprecated since Python 3.3,and in 3.9 it will stop working

@cburgdorf
Copy link
Contributor Author

There will be no release: the ustream repo has been archived by the owner.

Considering that the project seems dead, I'd argue we should just cut a new major release and migrate Trinity to it. We can continue to backport further changes into the 0.x development line if the community demands it, but considering that this breaking change is really tiny and easy to resolve I do not actually see that even becoming an issue.

@cburgdorf cburgdorf force-pushed the christoph/refactor/named_tuple branch 2 times, most recently from 322feb6 to 5f2e7b2 Compare April 17, 2020 11:09
@cburgdorf
Copy link
Contributor Author

I have updated the change to preserve the current behavior of providing index access. I also tuned the tests to cover indexing access. What do you think about this @pipermerriam ?

I'd love to get this fixed as it's currently the main driver of nasty warnings in Trinity.

@pipermerriam
Copy link
Member

@carver any thoughts on the breaking change here. I'm inclined to :shipit: since we're still in the 0.x release line and thus I believe we're allowed to introduce breaking changes in minor point releases.

@cburgdorf
Copy link
Contributor Author

@pipermerriam what's the remaining breaking change now that I added index access support?

@@ -507,7 +508,7 @@ def sign_message(self, signable_message: SignableMessage, private_key):
:param private_key: the key to sign the message with
:type private_key: hex str, bytes, int or :class:`eth_keys.datatypes.PrivateKey`
:returns: Various details about the signature - most importantly the fields: v, r, and s
:rtype: ~eth_account.datastructures.AttributeDict
:rtype: ~eth_account.datastructures.SignedMessage
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting that the doctests (which were supposedly checked recently) didn't catch that the returned value changes below.

I would expect there to be a number of places in the docs where this would change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just spent 1,5 hour to depuzzle this and here's the best I know so far:

  1. We never had any doctest running in this repo so far. I wasn't able to find a single CI run that ran any doctests (even though they exist)

  2. Then I found Doctests for Account and other general doc cleanup #94 which seems to fix this (it reports running 50 tests)

I'd happily rebase this on top of #94 but in case #94 needs more time to finish it should be easy to rebase that one on top of these changes, too.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤦 I totally lost track of #94. I just updated and it should be ready to merge. @cburgdorf I'm happy to pull your changes into #94, or vice versa, whatever is easier! Just let me know.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kclowes I don't have merge rights in this repo. If you have merge rights then feel free to merge both PRs in any preferred order.

@carver
Copy link
Contributor

carver commented Apr 17, 2020

@pipermerriam what's the remaining breaking change now that I added index access support?

For very type-conscious consumers, it could still break their tests. Maybe their mypy tests or doctests. (Maybe even projects like web3.py?)

I have always preferred a more duck-typing approach, but with the strict-typing tactic used in a lot of our projects, we might still be forced to do it is a v0 minor release (which we have been using to indicate a breaking change).

I still think it's a good change to keep the indexing access to minimize the cost of updating downstream projects. 👍

Copy link
Member

@pipermerriam pipermerriam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 didn't see that the breaking change had been fixed. 👍

@cburgdorf cburgdorf force-pushed the christoph/refactor/named_tuple branch from 5f2e7b2 to f1d68de Compare April 20, 2020 08:22
@pipermerriam
Copy link
Member

@cburgdorf I merged the other PR, mind rebasing to make sure everything is still good here and then I'll get this merged.

@cburgdorf cburgdorf force-pushed the christoph/refactor/named_tuple branch from f1d68de to 94dabda Compare April 21, 2020 14:52
@cburgdorf
Copy link
Contributor Author

@pipermerriam rebased and ready to 🚢

@pipermerriam pipermerriam merged commit 8cb6582 into ethereum:master Apr 21, 2020
@pipermerriam
Copy link
Member

@carver can you handle the release?

@carver
Copy link
Contributor

carver commented Apr 21, 2020

Seems like a fuzzy gray area of incompatibility. I'll just be sure to highlight it in the release notes. I just checked web3.py, and it doesn't have any reference to AttributeDict being returned by eth-account AFAICT.

So I'll go ahead and release this as a patch release.

@carver
Copy link
Contributor

carver commented Apr 22, 2020

It's a little late today, so I'll aim for Thursday morning.

pacrob added a commit to pacrob/eth-account that referenced this pull request Apr 26, 2023
* remove gitter, testing setup, and pandoc sections, add quotes to dev install
pacrob added a commit to pacrob/eth-account that referenced this pull request Jan 30, 2024
* remove gitter, testing setup, and pandoc sections, add quotes to dev install
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants